home *** CD-ROM | disk | FTP | other *** search
/ ftp.ac-grenoble.fr / 2015.02.ftp.ac-grenoble.fr.tar / ftp.ac-grenoble.fr / assistance.logicielle / NetTime-2b6.exe / {app} / RFC2030.txt < prev    next >
Text File  |  2000-08-07  |  50KB  |  1,008 lines
  1. Network Working Group                                           D. Mills
  2. Request for Comments: 2030                        University of Delaware
  3. Obsoletes: 1769                                             October 1996
  4. Category: Informational
  5.  
  6.  
  7.              Simple Network Time Protocol (SNTP) Version 4
  8.                          for IPv4, IPv6 and OSI
  9.  
  10. Status of this Memo
  11.  
  12.    This memo provides information for the Internet community.  This memo
  13.    does not specify an Internet standard of any kind.  Distribution of
  14.    this memo is unlimited.
  15.  
  16. Abstract
  17.  
  18.    This memorandum describes the Simple Network Time Protocol (SNTP)
  19.    Version 4, which is an adaptation of the Network Time Protocol (NTP)
  20.    used to synchronize computer clocks in the Internet. SNTP can be used
  21.    when the ultimate performance of the full NTP implementation
  22.    described in RFC-1305 is not needed or justified. When operating with
  23.    current and previous NTP and SNTP versions, SNTP Version 4 involves
  24.    no changes to the NTP specification or known implementations, but
  25.    rather a clarification of certain design features of NTP which allow
  26.    operation in a simple, stateless remote-procedure call (RPC) mode
  27.    with accuracy and reliability expectations similar to the UDP/TIME
  28.    protocol described in RFC-868.
  29.  
  30.    The only significant protocol change in SNTP Version 4 over previous
  31.    versions of NTP and SNTP is a modified header interpretation to
  32.    accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI
  33.    [COL94] addressing. However, SNTP Version 4 includes certain optional
  34.    extensions to the basic Version 3 model, including an anycast mode
  35.    and an authentication scheme designed specifically for multicast and
  36.    anycast modes. While the anycast mode extension is described in this
  37.    document, the authentication scheme extension will be described in
  38.    another document to be published later. Until such time that a
  39.    definitive specification is published, these extensions should be
  40.    considered provisional.
  41.  
  42.    This memorandum obsoletes RFC-1769, which describes SNTP Version 3.
  43.    Its purpose is to correct certain inconsistencies in the previous
  44.    document and to clarify header formats and protocol operations for
  45.    current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 and
  46.    OSI), which are also used for SNTP. A working knowledge of the NTP
  47.    Version 3 specification RFC-1305 is not required for an
  48.    implementation of SNTP.
  49.  
  50.  
  51.  
  52. Mills                        Informational                      [Page 1]
  53.  
  54. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  55.  
  56.  
  57. 1. Introduction
  58.  
  59.    The Network Time Protocol (NTP) Version 3 specified in RFC-1305
  60.    [MIL92] is widely used to synchronize computer clocks in the global
  61.    Internet. It provides comprehensive mechanisms to access national
  62.    time and frequency dissemination services, organize the time-
  63.    synchronization subnet and adjust the local clock in each
  64.    participating subnet peer. In most places of the Internet of today,
  65.    NTP provides accuracies of 1-50 ms, depending on the characteristics
  66.    of the synchronization source and network paths.
  67.  
  68.    RFC-1305 specifies the NTP Version 3 protocol machine in terms of
  69.    events, states, transition functions and actions and, in addition,
  70.    engineered algorithms to improve the timekeeping quality and mitigate
  71.    among several synchronization sources, some of which may be faulty.
  72.    To achieve accuracies in the low milliseconds over paths spanning
  73.    major portions of the Internet of today, these intricate algorithms,
  74.    or their functional equivalents, are necessary. However, in many
  75.    cases accuracies in the order of significant fractions of a second
  76.    are acceptable. In such cases, simpler protocols such as the Time
  77.    Protocol [POS83], have been used for this purpose. These protocols
  78.    usually involve an RPC exchange where the client requests the time of
  79.    day and the server returns it in seconds past some known reference
  80.    epoch.
  81.  
  82.    NTP is designed for use by clients and servers with a wide range of
  83.    capabilities and over a wide range of network delays and jitter
  84.    characteristics. Most users of the Internet NTP synchronization
  85.    subnet of today use a software package including the full suite of
  86.    NTP options and algorithms, which are relatively complex, real-time
  87.    applications (see http://www.eecis.udel.edu/~ntp). While the software
  88.    has been ported to a wide variety of hardware platforms ranging from
  89.    personal computers to supercomputers, its sheer size and complexity
  90.    is not appropriate for many applications. Accordingly, it is useful
  91.    to explore alternative access strategies using simpler software
  92.    appropriate for less stringent accuracy expectations.
  93.  
  94.    This document describes the Simple Network Time Protocol (SNTP)
  95.    Version 4, which is a simplified access strategy for servers and
  96.    clients using NTP Version 3 as now specified and deployed in the
  97.    Internet, as well as NTP Version 4 now under development. The access
  98.    paradigm is identical to the UDP/TIME Protocol and, in fact, it
  99.    should be easily possible to adapt a UDP/TIME client implementation,
  100.    say for a personal computer, to operate using SNTP. Moreover, SNTP is
  101.    also designed to operate in a dedicated server configuration
  102.    including an integrated radio clock. With careful design and control
  103.    of the various latencies in the system, which is practical in a
  104.    dedicated design, it is possible to deliver time accurate to the
  105.  
  106.  
  107.  
  108. Mills                        Informational                      [Page 2]
  109.  
  110. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  111.  
  112.  
  113.    order of microseconds.
  114.  
  115.    SNTP Version 4 is designed to coexist with existing NTP and SNTP
  116.    Version 3 clients and servers, as well as proposed Version 4 clients
  117.    and servers. When operating with current and previous versions of NTP
  118.    and SNTP, SNTP Version 4 requires no changes to the protocol or
  119.    implementations now running or likely to be implemented specifically
  120.    for NTP ir SNTP Version 4. To a NTP or SNTP server, NTP and SNTP
  121.    clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP
  122.    servers are undistinguishable. Like NTP servers operating in non-
  123.    symmetric modes, SNTP servers are stateless and can support large
  124.    numbers of clients; however, unlike most NTP clients, SNTP clients
  125.    normally operate with only a single server. NTP and SNTP Version 3
  126.    servers can operate in unicast and multicast modes. In addition, SNTP
  127.    Version 4 clients and servers can implement extensions to operate in
  128.    anycast mode.
  129.  
  130.    It is strongly recommended that SNTP be used only at the extremities
  131.    of the synchronization subnet. SNTP clients should operate only at
  132.    the leaves (highest stratum) of the subnet and in configurations
  133.    where no NTP or SNTP client is dependent on another SNTP client for
  134.    synchronization. SNTP servers should operate only at the root
  135.    (stratum 1) of the subnet and then only in configurations where no
  136.    other source of synchronization other than a reliable radio or modem
  137.    time service is available. The full degree of reliability ordinarily
  138.    expected of primary servers is possible only using the redundant
  139.    sources, diverse subnet paths and crafted algorithms of a full NTP
  140.    implementation. This extends to the primary source of synchronization
  141.    itself in the form of multiple radio or modem sources and backup
  142.    paths to other primary servers should all sources fail or the
  143.    majority deliver incorrect time. Therefore, the use of SNTP rather
  144.    than NTP in primary servers should be carefully considered.
  145.  
  146.    An important provision in this document is the reinterpretation of
  147.    certain NTP Versino 4 header fields which provide for IPv6 and OSI
  148.    addressing and optional anycast extensions designed specifically for
  149.    multicast service. These additions are in conjunction with the
  150.    proposed NTP Version 4 specification, which will appear as a separate
  151.    document. The only difference between the current NTP Version 3 and
  152.    proposed NTP Version 4 header formats is the interpretation of the
  153.    four-octet Reference Identifier field, which is used primarily to
  154.    detect and avoid synchronization loops. In Version 3 and Version 4
  155.    primary (stratum-1) servers, this field contains the four-character
  156.    ASCII reference identifier defined later in this document. In Version
  157.    3 secondary servers and clients, it contains the 32-bit IPv4 address
  158.    of the synchronization source. In Version 4 secondary servers and
  159.    clients, it contains the low order 32 bits of the last transmit
  160.    timestamp received from the synchronization source.
  161.  
  162.  
  163.  
  164. Mills                        Informational                      [Page 3]
  165.  
  166. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  167.  
  168.  
  169.    In the case of OSI, the Connectionless Transport Service (CLTS) is
  170.    used [ISO86]. Each SNTP packet is transmitted as tht TS-Userdata
  171.    parameter of a T-UNITDATA Request primitive. Alternately, the header
  172.    can be encapsulated in a TPDU which itself is transported using UDP
  173.    [DOB91]. It is not advised that NTP be operated at the upper layers
  174.    of the OSI stack, such as might be inferred from [FUR94], as this
  175.    could seriously degrade accuracy. With the header formats defined in
  176.    this document, it is in principle possible to interwork between
  177.    servers and clients of one protocol family and another, although the
  178.    practical difficulties may make this inadvisable.
  179.  
  180.       In the following, indented paragraphs such as this one contain
  181.       information not required by the formal protocol specification, but
  182.       considered good practice in protocol implementations.
  183.  
  184. 2. Operating Modes and Addressing
  185.  
  186.    SNTP Version 4 can operate in either unicast (point to point),
  187.    multicast (point to multipoint) or anycast (multipoint to point)
  188.    modes. A unicast client sends a request to a designated server at its
  189.    unicast address and expects a reply from which it can determine the
  190.    time and, optionally, the roundtrip delay and local clock offset
  191.    relative to the server. A multicast server periodically sends a
  192.    unsolicited message to a designated IPv4 or IPv6 local broadcast
  193.    address or multicast group address and ordinarily expects no requests
  194.    from clients. A multicast client listens on this address and
  195.    ordinarily sends no requests. An anycast client sends a request to a
  196.    designated IPv4 or IPv6 local broadcast address or multicast group
  197.    address. One or more anycast servers reply with their individual
  198.    unicast addresses. The client binds to the first one received, then
  199.    continues operation in unicast mode.
  200.  
  201.       Multicast servers should respond to client unicast requests, as
  202.       well as send unsolicited multicast messages. Multicast clients may
  203.       send unicast requests in order to determine the network
  204.       propagation delay between the server and client and then continue
  205.       operation in multicast mode.
  206.  
  207.    In unicast mode, the client and server end-system addresses are
  208.    assigned following the usual IPv4, IPv6 or OSI conventions. In
  209.    multicast mode, the server uses a designated local broadcast address
  210.    or multicast group address. An IP local broadcast address has scope
  211.    limited to a single IP subnet, since routers do not propagate IP
  212.    broadcast datagrams. On the other hand, an IP multicast group address
  213.    has scope extending to potentially the entire Internet. The scoping,
  214.    routing and group membership procedures are determined by
  215.    considerations beyond the scope of this document. For IPv4, the IANA
  216.    has assigned the multicast group address 224.0.1.1 for NTP, which is
  217.  
  218.  
  219.  
  220. Mills                        Informational                      [Page 4]
  221.  
  222. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  223.  
  224.  
  225.    used both by multicast servers and anycast clients. NTP multicast
  226.    addresses for IPv6 and OSI have yet to be determined.
  227.  
  228.    Multicast clients listen on the designated local broadcast address or
  229.    multicast group address. In the case of local broadcast addresses, no
  230.    further provisions are necessary. In the case of IP multicast
  231.    addresses, the multicast client and anycast server must implement the
  232.    Internet Group Management Protocol (IGMP) [DEE89], in order that the
  233.    local router joins the multicast group and relays messages to the
  234.    IPv4 or IPv6 multicast group addresses assigned by the IANA. Other
  235.    than the IP addressing conventions and IGMP, there is no difference
  236.    in server or client operations with either the local broadcast
  237.    address or multicast group address.
  238.  
  239.       It is important to adjust the time-to-live (TTL) field in the IP
  240.       header of multicast messages to a reasonable value, in order to
  241.       limit the network resources used by this (and any other) multicast
  242.       service. Only multicast clients in scope will receive multicast
  243.       server messages. Only cooperating anycast servers in scope will
  244.       reply to a client request. The engineering principles which
  245.       determine the proper value to be used are beyond the scope of this
  246.       document.
  247.  
  248.    Anycast mode is designed for use with a set of cooperating servers
  249.    whose addresses are not known beforehand by the client. An anycast
  250.    client sends a request to the designated local broadcast or multicast
  251.    group address as described below. For this purpose, the NTP multicast
  252.    group address assigned by the IANA is used. One or more anycast
  253.    servers listen on the designated local broadcast address or multicast
  254.    group address. Each anycast server, upon receiving a request, sends a
  255.    unicast reply message to the originating client. The client then
  256.    binds to the first such message received and continues operation in
  257.    unicast mode. Subsequent replies from other anycast servers are
  258.    ignored.
  259.  
  260.       In the case of SNTP as specified herein, there is a very real
  261.       vulnerability that SNTP multicast clients can be disrupted by
  262.       misbehaving or hostile SNTP or NTP multicast servers elsewhere in
  263.       the Internet, since at present all such servers use the same IPv4
  264.       multicast group address assigned by the IANA. Where necessary,
  265.       access control based on the server source address can be used to
  266.       select only the designated server known to and trusted by the
  267.       client. The use of cryptographic authentication scheme defined in
  268.       RFC-1305 is optional; however, implementors should be advised that
  269.       extensions to this scheme are planned specifically for NTP
  270.       multicast and anycast modes.
  271.  
  272.  
  273.  
  274.  
  275.  
  276. Mills                        Informational                      [Page 5]
  277.  
  278. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  279.  
  280.  
  281.       While not integral to the SNTP specification, it is intended that
  282.       IP broadcast addresses will be used primarily in IP subnets and
  283.       LAN segments including a fully functional NTP server with a number
  284.       of dependent SNTP multicast clients on the same subnet, while IP
  285.       multicast group addresses will be used only in cases where the TTL
  286.       is engineered specifically for each service domain.
  287.  
  288.       In NTP Version 3, the reference identifier was often used to
  289.       walk-back the synchronization subnet to the root (primary server)
  290.       for management purposes. In NTP Version 4, this feature is not
  291.       available, since the addresses are longer than 32 bits. However,
  292.       the intent in the protocol design was to provide a way to detect
  293.       and avoid loops. A peer could determine that a loop was possible
  294.       by comparing the contents of this field with the IPv4 destination
  295.       address in the same packet. A NTP Version 4 server can accomplish
  296.       the same thing by comparing the contents of this field with the
  297.       low order 32 bits of the originate timestamp in the same packet.
  298.       There is a small possibility of false alarm in this scheme, but
  299.       the false alarm rate can be minimized by randomizing the low order
  300.       unused bits of the transmit timestamp.
  301.  
  302. 3. NTP Timestamp Format
  303.  
  304.    SNTP uses the standard NTP timestamp format described in RFC-1305 and
  305.    previous versions of that document. In conformance with standard
  306.    Internet practice, NTP data are specified as integer or fixed-point
  307.    quantities, with bits numbered in big-endian fashion from 0 starting
  308.    at the left, or high-order, position. Unless specified otherwise, all
  309.    quantities are unsigned and may occupy the full field width with an
  310.    implied 0 preceding bit 0.
  311.  
  312.    Since NTP timestamps are cherished data and, in fact, represent the
  313.    main product of the protocol, a special timestamp format has been
  314.    established. NTP timestamps are represented as a 64-bit unsigned
  315.    fixed-point number, in seconds relative to 0h on 1 January 1900. The
  316.    integer part is in the first 32 bits and the fraction part in the
  317.    last 32 bits. In the fraction part, the non-significant low order can
  318.    be set to 0.
  319.  
  320.       It is advisable to fill the non-significant low order bits of the
  321.       timestamp with a random, unbiased bitstring, both to avoid
  322.       systematic roundoff errors and as a means of loop detection and
  323.       replay detection (see below). One way of doing this is to generate
  324.       a random bitstring in a 64-bit word, then perform an arithmetic
  325.       right shift a number of bits equal to the number of significant
  326.       bits of the timestamp, then add the result to the original
  327.       timestamp.
  328.  
  329.  
  330.  
  331.  
  332. Mills                        Informational                      [Page 6]
  333.  
  334. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  335.  
  336.  
  337.    This format allows convenient multiple-precision arithmetic and
  338.    conversion to UDP/TIME representation (seconds), but does complicate
  339.    the conversion to ICMP Timestamp message representation, which is in
  340.    milliseconds. The maximum number that can be represented is
  341.    4,294,967,295 seconds with a precision of about 200 picoseconds,
  342.    which should be adequate for even the most exotic requirements.
  343.  
  344.                         1                   2                   3
  345.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  346.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  347.    |                           Seconds                             |
  348.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  349.    |                  Seconds Fraction (0-padded)                  |
  350.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  351.  
  352.    Note that, since some time in 1968 (second 2,147,483,648) the most
  353.    significant bit (bit 0 of the integer part) has been set and that the
  354.    64-bit field will overflow some time in 2036 (second 4,294,967,296).
  355.    Should NTP or SNTP be in use in 2036, some external means will be
  356.    necessary to qualify time relative to 1900 and time relative to 2036
  357.    (and other multiples of 136 years). There will exist a 200-picosecond
  358.    interval, henceforth ignored, every 136 years when the 64-bit field
  359.    will be 0, which by convention is interpreted as an invalid or
  360.    unavailable timestamp.
  361.  
  362.       As the NTP timestamp format has been in use for the last 17 years,
  363.       it remains a possibility that it will be in use 40 years from now
  364.       when the seconds field overflows. As it is probably inappropriate
  365.       to archive NTP timestamps before bit 0 was set in 1968, a
  366.       convenient way to extend the useful life of NTP timestamps is the
  367.       following convention: If bit 0 is set, the UTC time is in the
  368.       range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1
  369.       January 1900. If bit 0 is not set, the time is in the range 2036-
  370.       2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February
  371.       2036. Note that when calculating the correspondence, 2000 is not a
  372.       leap year. Note also that leap seconds are not counted in the
  373.       reckoning.
  374.  
  375. 4. NTP Message Format
  376.  
  377.    Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
  378.    [POS80], which itself is a client of the Internet Protocol (IP)
  379.    [DAR81]. The structure of the IP and UDP headers is described in the
  380.    cited specification documents and will not be detailed further here.
  381.    The UDP port number assigned to NTP is 123, which should be used in
  382.    both the Source Port and Destination Port fields in the UDP header.
  383.    The remaining UDP header fields should be set as described in the
  384.    specification.
  385.  
  386.  
  387.  
  388. Mills                        Informational                      [Page 7]
  389.  
  390. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  391.  
  392.  
  393.    Below is a description of the NTP/SNTP Version 4 message format,
  394.    which follows the IP and UDP headers. This format is identical to
  395.    that described in RFC-1305, with the exception of the contents of the
  396.    reference identifier field. The header fields are defined as follows:
  397.  
  398.                            1                   2                   3
  399.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  400.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  401.       |LI | VN  |Mode |    Stratum    |     Poll      |   Precision   |
  402.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  403.       |                          Root Delay                           |
  404.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  405.       |                       Root Dispersion                         |
  406.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  407.       |                     Reference Identifier                      |
  408.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  409.       |                                                               |
  410.       |                   Reference Timestamp (64)                    |
  411.       |                                                               |
  412.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  413.       |                                                               |
  414.       |                   Originate Timestamp (64)                    |
  415.       |                                                               |
  416.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  417.       |                                                               |
  418.       |                    Receive Timestamp (64)                     |
  419.       |                                                               |
  420.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421.       |                                                               |
  422.       |                    Transmit Timestamp (64)                    |
  423.       |                                                               |
  424.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  425.       |                 Key Identifier (optional) (32)                |
  426.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  427.       |                                                               |
  428.       |                                                               |
  429.       |                 Message Digest (optional) (128)               |
  430.       |                                                               |
  431.       |                                                               |
  432.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  433.  
  434.    As described in the next section, in SNTP most of these fields are
  435.    initialized with pre-specified data. For completeness, the function
  436.    of each field is briefly summarized below.
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444. Mills                        Informational                      [Page 8]
  445.  
  446. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  447.  
  448.  
  449.    Leap Indicator (LI): This is a two-bit code warning of an impending
  450.    leap second to be inserted/deleted in the last minute of the current
  451.    day, with bit 0 and bit 1, respectively, coded as follows:
  452.  
  453.       LI       Value     Meaning
  454.       -------------------------------------------------------
  455.       00       0         no warning
  456.       01       1         last minute has 61 seconds
  457.       10       2         last minute has 59 seconds)
  458.       11       3         alarm condition (clock not synchronized)
  459.  
  460.    Version Number (VN): This is a three-bit integer indicating the
  461.    NTP/SNTP version number. The version number is 3 for Version 3 (IPv4
  462.    only) and 4 for Version 4 (IPv4, IPv6 and OSI). If necessary to
  463.    distinguish between IPv4, IPv6 and OSI, the encapsulating context
  464.    must be inspected.
  465.  
  466.    Mode: This is a three-bit integer indicating the mode, with values
  467.    defined as follows:
  468.  
  469.       Mode     Meaning
  470.       ------------------------------------
  471.       0        reserved
  472.       1        symmetric active
  473.       2        symmetric passive
  474.       3        client
  475.       4        server
  476.       5        broadcast
  477.       6        reserved for NTP control message
  478.       7        reserved for private use
  479.  
  480.    In unicast and anycast modes, the client sets this field to 3
  481.    (client) in the request and the server sets it to 4 (server) in the
  482.    reply. In multicast mode, the server sets this field to 5
  483.    (broadcast).
  484.  
  485.    Stratum: This is a eight-bit unsigned integer indicating the stratum
  486.    level of the local clock, with values defined as follows:
  487.  
  488.       Stratum  Meaning
  489.       ----------------------------------------------
  490.       0        unspecified or unavailable
  491.       1        primary reference (e.g., radio clock)
  492.       2-15     secondary reference (via NTP or SNTP)
  493.       16-255   reserved
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500. Mills                        Informational                      [Page 9]
  501.  
  502. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  503.  
  504.  
  505.    Poll Interval: This is an eight-bit signed integer indicating the
  506.    maximum interval between successive messages, in seconds to the
  507.    nearest power of two. The values that can appear in this field
  508.    presently range from 4 (16 s) to 14 (16284 s); however, most
  509.    applications use only the sub-range 6 (64 s) to 10 (1024 s).
  510.  
  511.    Precision: This is an eight-bit signed integer indicating the
  512.    precision of the local clock, in seconds to the nearest power of two.
  513.    The values that normally appear in this field range from -6 for
  514.    mains-frequency clocks to -20 for microsecond clocks found in some
  515.    workstations.
  516.  
  517.    Root Delay: This is a 32-bit signed fixed-point number indicating the
  518.    total roundtrip delay to the primary reference source, in seconds
  519.    with fraction point between bits 15 and 16. Note that this variable
  520.    can take on both positive and negative values, depending on the
  521.    relative time and frequency offsets. The values that normally appear
  522.    in this field range from negative values of a few milliseconds to
  523.    positive values of several hundred milliseconds.
  524.  
  525.    Root Dispersion: This is a 32-bit unsigned fixed-point number
  526.    indicating the nominal error relative to the primary reference
  527.    source, in seconds with fraction point between bits 15 and 16. The
  528.    values that normally appear in this field range from 0 to several
  529.    hundred milliseconds.
  530.  
  531.    Reference Identifier: This is a 32-bit bitstring identifying the
  532.    particular reference source. In the case of NTP Version 3 or Version
  533.    4 stratum-0 (unspecified) or stratum-1 (primary) servers, this is a
  534.    four-character ASCII string, left justified and zero padded to 32
  535.    bits. In NTP Version 3 secondary servers, this is the 32-bit IPv4
  536.    address of the reference source. In NTP Version 4 secondary servers,
  537.    this is the low order 32 bits of the latest transmit timestamp of the
  538.    reference source. NTP primary (stratum 1) servers should set this
  539.    field to a code identifying the external reference source according
  540.    to the following list. If the external reference is one of those
  541.    listed, the associated code should be used. Codes for sources not
  542.    listed can be contrived as appropriate.
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556. Mills                        Informational                     [Page 10]
  557.  
  558. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  559.  
  560.  
  561.       Code     External Reference Source
  562.       ----------------------------------------------------------------
  563.       LOCL     uncalibrated local clock used as a primary reference for
  564.                a subnet without external means of synchronization
  565.       PPS      atomic clock or other pulse-per-second source
  566.                individually calibrated to national standards
  567.       ACTS     NIST dialup modem service
  568.       USNO     USNO modem service
  569.       PTB      PTB (Germany) modem service
  570.       TDF      Allouis (France) Radio 164 kHz
  571.       DCF      Mainflingen (Germany) Radio 77.5 kHz
  572.       MSF      Rugby (UK) Radio 60 kHz
  573.       WWV      Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
  574.       WWVB     Boulder (US) Radio 60 kHz
  575.       WWVH     Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz
  576.       CHU      Ottawa (Canada) Radio 3330, 7335, 14670 kHz
  577.       LORC     LORAN-C radionavigation system
  578.       OMEG     OMEGA radionavigation system
  579.       GPS      Global Positioning Service
  580.       GOES     Geostationary Orbit Environment Satellite
  581.  
  582.    Reference Timestamp: This is the time at which the local clock was
  583.    last set or corrected, in 64-bit timestamp format.
  584.  
  585.    Originate Timestamp: This is the time at which the request departed
  586.    the client for the server, in 64-bit timestamp format.
  587.  
  588.    Receive Timestamp: This is the time at which the request arrived at
  589.    the server, in 64-bit timestamp format.
  590.  
  591.    Transmit Timestamp: This is the time at which the reply departed the
  592.    server for the client, in 64-bit timestamp format.
  593.  
  594.    Authenticator (optional): When the NTP authentication scheme is
  595.    implemented, the Key Identifier and Message Digest fields contain the
  596.    message authentication code (MAC) information defined in Appendix C
  597.    of RFC-1305.
  598.  
  599. 5. SNTP Client Operations
  600.  
  601.    A SNTP client can operate in multicast mode, unicast mode or anycast
  602.    mode. In multicast mode, the client sends no request and waits for a
  603.    broadcast (mode 5) from a designated multicast server. In unicast
  604.    mode, the client sends a request (mode 3) to a designated unicast
  605.    server and expects a reply (mode 4) from that server. In anycast
  606.    mode, the client sends a request (mode 3) to a designated local
  607.    broadcast or multicast group address and expects a reply (mode 4)
  608.    from one or more anycast servers. The client uses the first reply
  609.  
  610.  
  611.  
  612. Mills                        Informational                     [Page 11]
  613.  
  614. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  615.  
  616.  
  617.    received to establish the particular server for subsequent unicast
  618.    operations. Later replies from this server (duplicates) or any other
  619.    server are ignored. Other than the selection of address in the
  620.    request, the operations of anycast and unicast clients are identical.
  621.    Requests are normally sent at intervals from 64 s to 1024 s,
  622.    depending on the frequency tolerance of the client clock and the
  623.    required accuracy.
  624.  
  625.    A unicast or anycast client initializes the NTP message header, sends
  626.    the request to the server and strips the time of day from the
  627.    Transmit Timestamp field of the reply. For this purpose, all of the
  628.    NTP header fields shown above can be set to 0, except the first octet
  629.    and (optional) Transmit Timestamp fields. In the first octet, the LI
  630.    field is set to 0 (no warning) and the Mode field is set to 3
  631.    (client). The VN field must agree with the version number of the
  632.    NTP/SNTP server; however, Version 4 servers will also accept previous
  633.    versions. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers
  634.    already accept all previous versions, including Version 1 (RFC-1059).
  635.    Note that Version 0 (RFC-959) is no longer supported by any other
  636.    version.
  637.  
  638.    Since there will probably continue to be NTP and SNTP servers of all
  639.    four versions interoperating in the Internet, careful consideration
  640.    should be given to the version used by SNTP Version 4 clients. It is
  641.    recommended that clients use the latest version known to be supported
  642.    by the selected server in the interest of the highest accuracy and
  643.    reliability. SNTP Version 4 clients can interoperate with all
  644.    previous version NTP and SNTP servers, since the header fields used
  645.    by SNTP clients are unchanged. Version 4 servers are required to
  646.    reply in the same version as the request, so the VN field of the
  647.    request also specifies the version of the reply.
  648.  
  649.    While not necessary in a conforming client implementation, in unicast
  650.    and anycast modes it highly recommended that the transmit timestamp
  651.    in the request is set to the time of day according to the client
  652.    clock in NTP timestamp format. This allows a simple calculation to
  653.    determine the propagation delay between the server and client and to
  654.    align the local clock generally within a few tens of milliseconds
  655.    relative to the server. In addition, this provides a simple method to
  656.    verify that the server reply is in fact a legitimate response to the
  657.    specific client request and avoid replays. In multicast mode, the
  658.    client has no information to calculate the propagation delay or
  659.    determine the validity of the server, unless the NTP authentication
  660.    scheme is used.
  661.  
  662.    To calculate the roundtrip delay d and local clock offset t relative
  663.    to the server, the client sets the transmit timestamp in the request
  664.    to the time of day according to the client clock in NTP timestamp
  665.  
  666.  
  667.  
  668. Mills                        Informational                     [Page 12]
  669.  
  670. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  671.  
  672.  
  673.    format. The server copies this field to the originate timestamp in
  674.    the reply and sets the receive timestamp and transmit timestamp to
  675.    the time of day according to the server clock in NTP timestamp
  676.    format.
  677.  
  678.    When the server reply is received, the client determines a
  679.    Destination Timestamp variable as the time of arrival according to
  680.    its clock in NTP timestamp format. The following table summarizes the
  681.    four timestamps.
  682.  
  683.       Timestamp Name          ID   When Generated
  684.       ------------------------------------------------------------
  685.       Originate Timestamp     T1   time request sent by client
  686.       Receive Timestamp       T2   time request received by server
  687.       Transmit Timestamp      T3   time reply sent by server
  688.       Destination Timestamp   T4   time reply received by client
  689.  
  690.    The roundtrip delay d and local clock offset t are defined as
  691.  
  692.       d = (T4 - T1) - (T2 - T3)     t = ((T2 - T1) + (T3 - T4)) / 2.
  693.  
  694.    The following table summarizes the SNTP client operations in unicast,
  695.    anycast and multicast modes. The recommended error checks are shown
  696.    in the Reply and Multicast columns in the table. The message should
  697.    be considered valid only if all the fields shown contain values in
  698.    the respective ranges. Whether to believe the message if one or more
  699.    of the fields marked "ignore" contain invalid values is at the
  700.    discretion of the implementation.
  701.  
  702.       Field Name              Unicast/Anycast          Multicast
  703.                               Request    Reply
  704.       ----------------------------------------------------------
  705.       LI                      0          0-2           0-2
  706.       VN                      1-4        copied from   1-4
  707.                                          request
  708.       Mode                    3          4             5
  709.       Stratum                 0          1-14          1-14
  710.       Poll                    0          ignore        ignore
  711.       Precision               0          ignore        ignore
  712.       Root Delay              0          ignore        ignore
  713.       Root Dispersion         0          ignore        ignore
  714.       Reference Identifier    0          ignore        ignore
  715.       Reference Timestamp     0          ignore        ignore
  716.       Originate Timestamp     0          (see text)    ignore
  717.       Receive Timestamp       0          (see text)    ignore
  718.       Transmit Timestamp      (see text) nonzero       nonzero
  719.       Authenticator           optional   optional      optional
  720.  
  721.  
  722.  
  723.  
  724. Mills                        Informational                     [Page 13]
  725.  
  726. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  727.  
  728.  
  729. 6. SNTP Server Operations
  730.  
  731.    A SNTP Version 4 server operating with either a NTP or SNTP client of
  732.    the same or previous versions retains no persistent state. Since a
  733.    SNTP server ordinarily does not implement the full set of NTP
  734.    algorithms intended to support redundant peers and diverse network
  735.    paths, a SNTP server should be operated only in conjunction with a
  736.    source of external synchronization, such as a reliable radio clock or
  737.    telephone modem. In this case it always operates as a primary
  738.    (stratum 1) server.
  739.  
  740.    A SNTP server can operate in unicast mode, anycast mode, multicast
  741.    mode or any combination of these modes. In unicast and anycast modes,
  742.    the server receives a request (mode 3), modifies certain fields in
  743.    the NTP header, and sends a reply (mode 4), possibly using the same
  744.    message buffer as the request. In anycast mode, the server listens on
  745.    the designated local broadcast or multicast group address assigned by
  746.    the IANA, but uses its own unicast address in the source address
  747.    field of the reply. Other than the selection of address in the reply,
  748.    the operations of anycast and unicast servers are identical.
  749.    Multicast messages are normally sent at poll intervals from 64 s to
  750.    1024 s, depending on the expected frequency tolerance of the client
  751.    clocks and the required accuracy.
  752.  
  753.    In unicast and anycast modes, the VN and Poll fields of the request
  754.    are copied intact to the reply. If the Mode field of the request is 3
  755.    (client), it is set to 4 (server) in the reply; otherwise, this field
  756.    is set to 2 (symmetric passive) in order to conform to the NTP
  757.    specification. This allows clients configured in symmetric active
  758.    (mode 1) to interoperate successfully, even if configured in possibly
  759.    suboptimal ways. In multicast (unsolicited) mode, the VN field is set
  760.    to 4, the Mode field is set to 5 (broadcast), and the Poll field set
  761.    to the nearest integer base-2 logarithm of the poll interval.
  762.  
  763.       Note that it is highly desirable that, if a server supports
  764.       multicast mode, it also supports unicast mode. This is so a
  765.       potential multicast client can calculate the propagation delay
  766.       using a client/server exchange prior to regular operation using
  767.       only multicast mode. If the server supports anycast mode, then it
  768.       must support unicast mode. There does not seem to be a great
  769.       advantage to operate both multicast and anycast modes at the same
  770.       time, although the protocol specification does not forbid it.
  771.  
  772.    In unicast and anycast modes, the server may or may not respond if
  773.    not synchronized to a correctly operating radio clock, but the
  774.    preferred option is to respond, since this allows reachability to be
  775.    determined regardless of synchronization state. In multicast mode,
  776.    the server sends broadcasts only if synchronized to a correctly
  777.  
  778.  
  779.  
  780. Mills                        Informational                     [Page 14]
  781.  
  782. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  783.  
  784.  
  785.    operating reference clock.
  786.  
  787.    The remaining fields of the NTP header are set in the following way.
  788.    Assuming the server is synchronized to a radio clock or other primary
  789.    reference source and operating correctly, the LI field is set to 0
  790.    and the Stratum field is set to 1 (primary server); if not, the
  791.    Stratum field is set to 0 and the LI field is set to 3. The Precision
  792.    field is set to reflect the maximum reading error of the local clock.
  793.    For all practical cases it is computed as the negative of the number
  794.    of significant bits to the right of the decimal point in the NTP
  795.    timestamp format. The Root Delay and Root Dispersion fields are set
  796.    to 0 for a primary server; optionally, the Root Dispersion field can
  797.    be set to a value corresponding to the maximum expected error of the
  798.    radio clock itself. The Reference Identifier is set to designate the
  799.    primary reference source, as indicated in the table of Section 5 of
  800.    this document.
  801.  
  802.    The timestamp fields are set as follows. If the server is
  803.    unsynchronized or first coming up, all timestamp fields are set to
  804.    zero. If synchronized, the Reference Timestamp is set to the time the
  805.    last update was received from the radio clock or modem. In unicast
  806.    and anycast modes, the Receive Timestamp and Transmit Timestamp
  807.    fields are set to the time of day when the message is sent and the
  808.    Originate Timestamp field is copied unchanged from the Transmit
  809.    Timestamp field of the request. It is important that this field be
  810.    copied intact, as a NTP client uses it to avoid replays. In multicast
  811.    mode, the Originate Timestamp and Receive Timestamp fields are set to
  812.    0 and the Transmit Timestamp field is set to the time of day when the
  813.    message is sent. The following table summarizes these actions.
  814.  
  815.       Field Name              Unicast/Anycast          Multicast
  816.                               Request    Reply
  817.       ----------------------------------------------------------
  818.       LI                      ignore     0 or 3        0 or 3
  819.       VN                      1-4        copied from   4
  820.                                          request
  821.       Mode                    3          2 or 4        5
  822.       Stratum                 ignore     1             1
  823.       Poll                    ignore     copied from   log2 poll
  824.                                          request       interval
  825.       Precision               ignore     -log2 server  -log2 server
  826.                                          significant   significant
  827.                                          bits          bits
  828.       Root Delay              ignore     0             0
  829.       Root Dispersion         ignore     0             0
  830.       Reference Identifier    ignore     source ident  source ident
  831.       Reference Timestamp     ignore     time of last  time of last
  832.                                          radio update  radio update
  833.  
  834.  
  835.  
  836. Mills                        Informational                     [Page 15]
  837.  
  838. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  839.  
  840.  
  841.       Originate Timestamp     ignore     copied from   0
  842.                                          transmit
  843.                                          timestamp
  844.       Receive Timestamp       ignore     time of day   0
  845.       Transmit Timestamp      (see text) time of day   time of day
  846.       Authenticator           optional   optional      optional
  847.  
  848.    There is some latitude on the part of most clients to forgive invalid
  849.    timestamps, such as might occur when first coming up or during
  850.    periods when the primary reference source is inoperative. The most
  851.    important indicator of an unhealthy server is the LI field, in which
  852.    a value of 3 indicates an unsynchronized condition. When this value
  853.    is displayed, clients should discard the server message, regardless
  854.    of the contents of other fields.
  855.  
  856. 7. Configuration and Management
  857.  
  858.    Initial setup for SNTP servers and clients can be done using a
  859.    configuration file if a file system is available, or a serial port if
  860.    not. It is intended that in-service management of NTP and SNTP
  861.    Version 4 servers and clients be performed using SNMP and a suitable
  862.    MIB to be published later. Ordinarily, SNTP servers and clients are
  863.    expected to operate with little or no site-specific configuration,
  864.    other than specifying the IP address and subnet mask or OSI NSAP
  865.    address.
  866.  
  867.    Unicast clients must be provided with the designated server name or
  868.    address. If a server name is used, the address of one of more DNS
  869.    servers must be provided. Multicast servers and anycast clients  must
  870.    be provided with the TTL and local broadcast or multicast group
  871.    address. Anycast servers and multicast clients may be configured with
  872.    a list of address-mask pairs for access control, so that only those
  873.    clients or servers known to be trusted will be used. These servers
  874.    and clients must implement the IGMP protocol and be provided with the
  875.    local broadcast or multicast group address as well. The configuration
  876.    data for cryptographic authentication is beyond the scope of this
  877.    document.
  878.  
  879.    There are several scenarios which provide automatic server discovery
  880.    and selection for SNTP clients with no pre-specified configuration,
  881.    other than the IP address and subnet mask or OSI NSAP address. For a
  882.    IP subnet or LAN segment including a fully functional NTP server, the
  883.    clients can be configured for multicast mode using the local
  884.    broadcast address. The same approach can be used with other servers
  885.    using the multicast group address. In both cases, provision of an
  886.    access control list is a good way to insure only trusted sources can
  887.    be used to set the local clock.
  888.  
  889.  
  890.  
  891.  
  892. Mills                        Informational                     [Page 16]
  893.  
  894. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  895.  
  896.  
  897.    In another scenario suitable for an extended network with significant
  898.    network propagation delays, clients can be configured for anycast
  899.    mode, both upon initial startup and after some period when the
  900.    currently selected unicast source has not been heard. Following the
  901.    defined protocol, the client binds to the first reply heard and
  902.    continues operation in unicast mode. In this mode the local clock can
  903.    be automatically adjusted to compensate for the propagation delay.
  904.  
  905.    In still another scenario suitable for any network and where
  906.    multicast service is not available, the DNS can be set up with a
  907.    common CNAME, like time.domain.net, and a list of address records for
  908.    NTP servers in the same domain. Upon resolving time.domain.net and
  909.    obtaining the list, the client selects a server at random and begins
  910.    operation in unicast mode with that server. Many variations on this
  911.    theme are possible.
  912.  
  913. 8. Acknowledgements
  914.  
  915.    Jeff Learman was helpful in developing the OSI model for this
  916.    protocol. Ajit Thyagarajan provided valuable suggestions and
  917.    corrections.
  918.  
  919. 9. References
  920.  
  921.    [COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines
  922.    for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.
  923.  
  924.    [DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791,
  925.    USC Information Sciences Institute, September 1981.
  926.  
  927.    [DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
  928.    RFC 1112, Stanford University, August 1989.
  929.  
  930.    [DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
  931.    Specification", RFC 1883, Xerox and Ipsilon, January 1996.
  932.  
  933.    [DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless
  934.    transport services on top of UDP - Version: 1", RFC 1240, Open
  935.    Software Foundation, June 1991.
  936.  
  937.    [EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System
  938.    Security Extensions", Work in Progress.
  939.  
  940.    [FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support
  941.    basic communications applications", RFC 1698, Consultant,
  942.    October 1994.
  943.  
  944.  
  945.  
  946.  
  947.  
  948. Mills                        Informational                     [Page 17]
  949.  
  950. RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996
  951.  
  952.  
  953.    [HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing
  954.    Architecture", RFC 1884, Ipsilon and Xerox, January 1996.
  955.  
  956.    [ISO86] International Standards 8602 - Information Processing Systems
  957.    - OSI: Connectionless Transport Protocol Specification. International
  958.    Standards Organization, December 1986.
  959.  
  960.    [MIL92] Mills, D., "Network Time Protocol (Version 3) specification,
  961.    implementation and analysis", RFC 1305, University of Delaware,
  962.    March 1992.
  963.  
  964.    [PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting
  965.    service", RFC 1546, Bolt Beranek Newman, November 1993.
  966.  
  967.    [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  968.    USC Information Sciences Institute, August 1980.
  969.  
  970.    [POS83] Postel, J., "Time Protocol", STD 26, RFC 868,
  971.    USC Information Sciences Institute, May 1983.
  972.  
  973. Security Considerations
  974.  
  975.    Security issues are not discussed in this memo.
  976.  
  977. Author's Address
  978.  
  979.    David L. Mills
  980.    Electrical Engineering Department
  981.    University of Delaware
  982.    Newark, DE 19716
  983.  
  984.    Phone: (302) 831-8247
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004. Mills                        Informational                     [Page 18]
  1005.  
  1006.  
  1007.  
  1008.